Large-scale software development efforts require proper coordination and management of teams of software engineers and test engineers. When a software development effort involves a large group of engineers simultaneously working on multiple versions and releases of a large number of different source modules of the software product, confusion and inefficiency easily results if the development process and subsequent product release are not properly managed.
For example, some engineers may be coding source modules for version 3.1 of a software product X, while some engineers may be incorporating newer features into source modules for version 4.0, and still some engineers may be providing a fix to some problems reported in source modules of version 2.1. Note that it is possible to have overlap between the three groups of engineers, so that an engineer may be involved in all three efforts.
Compounding the problem is the fact that each version of a software product must pass through multiple developmental stages prior to its release, where advancing to the next stage requires the passing of some predetermined testing and approval process. To be tested, all the source modules for that version of the software product must be collected and built into a load. The process of load building is also called compiling and linking of all the source modules. The resultant load or build is the software product to be tested or to be delivered to the customers when all the developmental stages have been passed.
Previously, the process of determining which source modules to collect, collecting the source modules, and building the load therefrom was tedious and time-consuming. Many hours were spent in meetings with software engineers and managers to determine which source modules should be included in which version, and what reported problems were fixed by which source modules, and whether the source modules with new features should be included in the present build. The end result is a list of source modules that is used to identify and pull the source modules, typically from a version control subsystem into which engineers have checked in their work. The source modules are then manually identified and compiled into a load, and manually downloaded into a storage medium such as a tape or compact disc for delivery to the customers.
In addition, the task of preparing and collecting the documentation related to specific versions and releases of the software product is daunting. Documentation may include those that are generated for internal usage and to document knowledge, and those generated for auditing purposes, and for customer training or education. These documentation may include project meeting minutes, requirements documentation, design specification documentation, standards checklist used when the project goes from one phase of development to the next, test cases, test reports, customer documentation and manuals, build procedures, build reports, etc. Therefore, it is a substantial task to ensure that documentation for a software product is properly associated with the correct version and release of software product.
It may be seen that because the process of building a software load and document preparation and collection are repeatedly performed in the development of the software product, considerable savings in time, energy, and funds are possible if the process is automated and made more efficient.